CSS-in-CSS, CSS-in-JS
April 28, 2021
어제 A 기업의 인터뷰를 진행중 코드리뷰를 하면서 한가지 예상못했던 문제점을 지적받았다.
styled-component와sass를 함께 사용하면 성능 저하를 유발할 수 있습니다.
background-image를 스타일시트에서 적용하거나, 동적 변수에 인한 스타일 변화가 있을 때에는 CSS-in-JS 방식인 styled-component를 사용하고, 그 외의 기본이 되는 스타일 들은 모두 CSS-in-CSS방식을 통해 두가지를 함께 사용해왔다.
이 방법이 성능 저하를 유발할 수 있는 문제였다니..
이런 문제를 지적받고, 열심히 구글링을 해 본 결과, 직접적인 답변은 없었지만 어느정도 이유를 예측할 수 있는 글을 발견하였다.
styled-component와 sass 모두 더 나은 스타일링을 위해 기본 프로젝트에 새롭게 받아야 하는 모듈들이다. 똑같은 작업을 하기 위해 두가지 각기 다른 모듈을 받는다는것 자체가 불필요한 소비 이므로 하나를 사용할 때 보다는 성능저하를 유발할 수 있다는게 맞는것 같다.
즉, 클라이언트가 초기 접속할 때 불필요한 라이브러리로 더 많은 번들링 시간을 갖게된다는것 같음
그때 질문 이후, 면접관님이
만약, 둘중 하나만 선택한다면 어떤것을 선택하시겠나요?
라는 질문을 하셨지만, 각각의 장점이 너무 명확해서 대답을 못하였다.. 정말 못고르겠다고..
따라서 선택을 하는데 도움이 되도록 CSS-in-JS의 장단점을 알아보려고 한다.
CSS-in-JS
가장 많이 사용되고있는 styled-components의 기반이 되는 기법이다.
장점
build time때 고유한 값으로class명이 자동으로 지정된다.- 스타일이 해당 컴포넌트 단위에서 형성되기 때문에,
css파일간 의존성이 사라진다. - 동적인 속성에 따른 스타일변경이 용이하다.
- 컴포넌트 내부에 작성되는 스타일이기 때문에, 사용하는 모듈의 사라지지않는 한 해당 파일 하나로 충분히 재활용이 가능하다.
- 컴포넌트별로 구분되어 있기 때문에, 스타일에대한 유지보수가 용이하다.
단점
- 아무래도 새로운 모듈을 받아서 사용하는것이기 때문에, 번들 사이즈가 커져서 비교적 늦는다고 한다.
- 기존
CSS-in-CSS의 경우 번들링된 하나의 스타일파일을 파싱한 뒤, 사용하는것이라 단 한번만 진행되지만,styled-components의 경우 각각의 컴포넌트가 형성될 때마다CSS코드를 읽어서 파싱하기 때문에 비교적 늦어진다고 한다. class명이 자동으로 생성이 되면서 빌드 또는 렌더링간 캐시 문제가 발생할 수 있다고 한다.- 컴포넌트 내부에 스타일이 있다는 점에서 재활용성이 뛰어난건 사실있지만, 포괄적이고 로직이 내부에 포함되어있기 때문에 디버깅이 좀 더 어렵다.
결론
CSS-in-JS를 통해 편리하고, 참신한 방법으르 스타일링을 하는 개발자도 있고, CSS-in-CSS의 기본방식을 통해 안정성과 보편적인 특성을 선호하는 개발자도 있는것 같았다. 두가지중 한가지를 선택하기보단 상황에 맞게 잘 사용하는것이 좋아보인다.
이후의 질문
특징을 알아보기위해 첫 질문만 예시를 들었지만, 사실 뒤에 꼬리질문이 있었다.
만약
sass만을 사용하게 된다면,background-image와 같은 경우는 어떻게 처리할건가요?
- 서버에 등록된 상대경로(
git)를 통해 지정한다. - 인라인 스타일을 통해
img태그의src와 유사하게process.env.PUBLIC_URL+public디렉토리에 접근하여 이미지를 사용한다.아래 방법이 가장 많이 추천되는 방법인듯 함..
스타일시트에서는 public 디렉토리에 접근을 할 수가 없는데, 그 이유로는 webpack 자체가 src를 기점으로 작동되기 떄문일듯 하다.
실제로, eject를 해보았을 때 src/index.js가 시작의 기점이되도록 설정이 되어있었고, 스타일시트에서 background-image 속성의 경로가 src 외부로 넘어가게 되는 순간 기준을 넘어갔다는 에러가 출력되었다.
이런점 때문에, styled-components를 같이 사용했었음..
